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Abstract 

Power  management  is  an  important  problem  in  battery-powered  sensor  networks  as  the  sen¬ 
sors  are  required  to  operate  for  a  long  time  (usually,  several  weeks  to  several  months).  One  of 
the  challenges  in  developing  power  management  protocols  for  sensor  networks  is  prototyping. 
Specifically,  existing  programming  platforms  for  sensor  networks  (e.g.,  nesC/TinyOS)  use  an 
event-driven  programming  model  and,  hence,  require  the  designers  to  be  responsible  for  stack 
management,  buffer  management,  flow  control,  etc.  Therefore,  the  designers  simplify  prototyp¬ 
ing  their  solutions  either  by  implementing  their  own  discrete  event  simulators  or  by  modeling 
them  in  specialized  simulators.  To  enable  the  designers  to  prototype  power  management  proto¬ 
cols  in  target  platform  (e.g.,  nesC/TinyOS),  in  this  paper,  we  use  ProSe,  a  programming  tool  for 
sensor  networks.  ProSe  enables  the  designers  to  specify  their  programs  in  simple  abstract  mod¬ 
els  while  hiding  low-level  challenges  of  sensor  networks  and  programming-level  challenges.  As  a 
case  study,  in  this  paper,  we  specify  a  power  management  protocol  with  ProSe,  automatically 
generate  the  corresponding  nesC/TinyOS  code,  and  evaluate  its  performance.  Based  on  the 
performance  results,  we  expect  that  ProSe  enables  the  designers  to  rapidly  prototype,  quickly 
deploy,  and  easily  evaluate  their  protocols. 
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1  Introduction 


In  the  recent  years,  sensor  networks  have  become  popular  due  to  their  wide  variety  of  applications 
including  border  patrolling,  hazard  detection,  habitat  monitoring,  and  micro-climate  monitoring. 
These  applications  require  the  network  to  operate  for  a  long  time  (usually,  several  weeks  to  several 
months).  However,  the  sensors  are  typically  battery-powered  (e.g.,  Mica  [1],  XSM  [2],  Telos  [3]) 
and,  hence,  they  can  operate  continuously  only  for  a  few  days.  In  addition,  since  the  sensors  are 
deployed  in  large  numbers  and  mostly  in  inaccessible  fields,  it  is  difficult  to  change  the  batteries 
after  deployment.  Therefore,  power  management  is  crucial  for  extending  the  lifetime  of  the  network. 

One  of  the  challenges  in  designing  power  management  protocols  for  sensor  networks  is  prototyping. 
Specifically,  existing  platforms  (e.g.,  nesC/TinyOS  [4])  for  programming  sensor  networks  use  event- 
driven  programming  model  and,  hence,  require  the  designer  be  responsible  for  stack  management, 
buffer  management,  and  flow  control  [5,6].  Therefore,  to  rapidly  prototype  and  quickly  evaluate 
protocols,  the  designers  of  existing  power  management  protocols  (e.g.,  [7-13])  implement  their  own 
simulators  or  model  their  protocols  in  specialized  simulators  (e.g.,  GloMoSim  [14]).  However,  it  is 
desirable  that  the  designers  prototype  their  protocols  in  nesC/TinyOS  platform  as  it  provides  a 
framework  for  generating  both  simulation  as  well  as  production  code  from  the  same  source. 

In  this  paper,  we  consider  the  problem  of  rapid  prototyping  of  power  management  protocols  in 
nesC/TinyOS  platform.  To  deal  with  programming  level  challenges  (e.g.,  stack  management, 
buffer  management,  flow  control,  etc)  and  network  level  challenges  (e.g.,  message  collision,  cor¬ 
ruption,  synchronization,  etc)  of  sensor  networks,  we  focus  on  ProSe  [15],  a  programming  tool  for 
rapid  prototyping  of  sensor  network  protocols  and  applications.  ProSe  is  based  on  the  theoretical 
foundation  on  computational  model  in  sensor  networks  [16,17].  It  enables  the  designers  to  (i)  spec¬ 
ify  programs  in  simple  abstract  models  (e.g.,  read/write  model,  shared- memory  model)  that  hide 
several  challenges  of  sensor  networks,  (ii)  automatically  transform  the  programs  into  a  model  con¬ 
sistent  with  sensor  networks,  (iii)  preserve  properties  such  as  self-stabilization  and  fault-tolerance 
in  the  transformed  programs,  and  (iv)  automatically  generate  and  deploy  (nesC/TinyOS)  binary. 

As  a  case  study,  we  model  pCover  [13],  a  power  management  protocol  that  provides  partial  (but 
high)  sensor  coverage  of  the  target  field,  in  ProSe.  We  specify  the  pCover  program  in  shared- 
memory  model.  We  synthesize  the  corresponding  nesC/TinyOS  binary  and  study  the  performance 
of  the  generated  code.  Through  simulations,  we  show  that  the  generated  program  extends  the 
lifetime  of  the  network  while  providing  a  partial  (but  high)  coverage. 

Organization  of  the  paper.  The  rest  of  the  paper  is  organized  as  follows.  In  Section  2,  we 
briefly  discuss  how  programs  are  specified  in  ProSe.  Then,  in  Section  3,  we  prototype  pCover  in 
ProSe.  We  present  a  brief  overview  of  the  protocol  and  discuss  how  we  synthesized  the  nesC/TinyOS 
binary.  Subsequently,  we  study  the  performance  of  the  generated  binary  code.  We  show  that  the 
generated  program  extends  the  lifetime  of  the  network.  Finally,  in  Section  4,  we  discuss  some  of 
the  questions  raised  by  this  work  and,  in  Section  5,  we  make  the  concluding  remarks. 

2  ProSe:  Overview 

In  this  section,  we  briefly  outline  the  structure  of  programs  in  ProSe  and  discuss  how  nesC/TinyOS 
binaries  are  synthesized. 
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2.1  Structure  of  Programs 

In  ProSe,  programs  are  specified  in  terms  of  guarded  commands  [18];  each  command  (or  action)  is 
of  the  form: 

guard  — >  statement, 

where  guard  is  a  predicate  over  program  variables,  and  statement  updates  program  variables.  An 
action  g  — *  st  is  enabled  when  g  evaluates  to  true  and  to  execute  that  action,  st  is  executed.  A 
computation  of  this  program  consists  of  a  sequence  so,  si, . . . ,  where  Sj+i  is  obtained  from  Sj  by 
executing  actions  in  the  program  (0  <  j). 

Computation  model.  A  computation  model  limits  the  variables  that  an  action  can  read  and 
write.  Towards  this  end,  we  split  the  program  actions  into  a  set  of  processes  (sensors).  Each  action 
is  associated  with  one  of  the  processes  (sensors)  in  the  program.  We  now  describe  how  we  model 
the  restrictions  imposed  by  shared- memory  model  and  read/write  model. 

Shared-memory  model.  In  this  model,  in  one  atomic  step,  a  sensor  can  read  its  state  as  well  as 
the  state  of  its  neighbors  and  write  its  own  ( public  and  private )  variables. 

Read/Write  model.  In  this  model,  in  one  atomic  step,  a  sensor  can  either  (1)  read  the  state  of  one 
of  its  neighbors  and  update  its  private  variables,  or  (2)  write  its  own  variables. 

Programs  written  in  shared- memory  model  or  read/write  model,  however,  are  not  suitable  for 
the  constraints  (and  opportunities)  provided  by  sensor  networks.  For  this  reason,  in  [16,17],  the 
authors  have  modeled  the  computations  in  sensor  networks  as  a  write  all  with  collision  (WAC) 
model,  discussed  next. 

Write  all  with  collision  (WAC)  model.  In  this  model,  each  sensor  consists  of  write  actions  (to 
be  precise,  write-all  actions).  Specifically,  in  one  atomic  action,  a  sensor  can  update  its  own  state 
and  the  state  of  all  its  neighbors.  However,  if  two  or  more  sensors  simultaneously  try  to  update 
the  state  of  a  sensor,  say  k,  then  the  state  of  k  remains  unchanged.  Thus,  this  model  captures  the 
fact  that  a  message  sent  by  a  sensor  is  broadcast.  But,  if  multiple  messages  are  sent  to  a  sensor 
simultaneously  then,  due  to  collision,  it  receives  none. 

To  simplify  programming  sensor  networks,  recently,  approaches  have  been  proposed  for  trans¬ 
forming  programs  into  WAC  model.  They  can  be  classified  as:  (a)  TDMA  based  deterministic 
transformation  [16]  and  (b)  CSMA  based  probabilistic  transformation  [17].  With  the  help  of  these 
transformation  algorithms,  ProSe  allows  the  designer  to  specify  programs  in  simple  abstract  models 
(e.g.,  shared- memory  model,  read/write  model).  Then,  ProSe  automatically  transforms  them  into 
WAC  model  and,  subsequently,  generates  the  corresponding  nesC/TinyOS  code. 

2.2  Input/Output  of  ProSe 

The  input  to  ProSe  consists  of  the  guarded  command  program  in  shared- memory  or  read/write 
model,  its  initial  states  and  (optionally)  the  topology  of  the  network.  We  discuss  the  input/output 
of  ProSe  in  the  context  of  an  example. 

Input  guarded  commands  program.  Consider  a  MAX  program,  where  each  process  (i.e., 
sensor)  maintains  a  public  variable  x.  The  goal  of  MAX  is  to  eventually  identify  the  maximum 
value  of  this  variable  across  the  network.  We  specify  the  actions  of  each  process  in  this  program  as 
follows  (keywords  are  shown  in  bold  font): 
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1  program  max 

2  sensor  j 

3  var  public  int  x .  j  ; 

4  begin 

5  (x.k  >  x.j)  ->  x.j  =  x.k; 

6  end 

7  init  state  x.j  =  j  ; 

The  designer  also  specifies  zero  or  more  initial  states  of  the  program.  If  no  initial  states  are  specified, 
ProSe  initializes  the  variables  of  the  program  to  arbitrary  values.  If  more  than  one  initial  states 
are  specified,  ProSe  initializes  the  program  to  randomly  selected  state.  In  the  above  program,  x.j 
is  initialized  to  j  (i.e.,  ID  of  the  sensor). 

Auxiliary  variables.  ProSe  provides  abstractions  to  deal  with  failure  of  sensors  and  presence 
of  Byzantine  sensors.  To  determine  whether  a  neighbor  (say,  k)  is  alive  or  failed,  sensor  j  can  just 
access  the  public  variable  up.k]  if  up.k  is  TRUE  (respectively,  FALSE)  then  k  is  alive  (respectively, 
failed).  Designers  can  use  this  abstract  variable  to  simplify  the  design  of  sensor  network  proto¬ 
cols  while  ProSe  provides  implementation  of  this  variable  through  heartbeat  protocol  (e.g.,  [19]). 
Similarly,  ProSe  also  allows  designers  to  model  Byzantine  sensors  through  abstract  variables  (b.j). 

Topology  information.  ProSe  wires  a  component  ( NeighborState )  that  maintains  the  state 
information  of  the  neighbors  at  each  sensor,  with  the  generated  code.  Towards  this  end,  each 
sensor  should  identify  its  neighborhood.  ProSe  allows  the  designers  to  integrate  a  neighborhood 
abstraction  layer  (e.g.,  [20])  with  the  generated  code.  Such  an  abstraction  layer  allows  a  sensor  to 
learn  its  neighborhood  dynamically.  Optionally,  the  designers  can  specify  the  static  topology  of  the 
network  as  an  input  to  ProSe  using  the  topology  file.  This  file  includes  the  ID  of  the  base  station, 
size  of  the  network,  and  the  communication  topology.  Based  on  the  neighborhood  information, 
ProSe  configures  the  MAC  layer  and  NeighborState  component. 

Support  for  component  invocations  in  guarded  commands.  Since  ProSe  allows  the  de¬ 
signers  to  specify  programs  in  guarded  commands  format,  it  makes  protocol  design  highly  intuitive 
and  concise.  However,  it  is  not  always  desirable  to  use  guarded  commands  to  specify  protocols.  For 
example,  consider  the  design  of  a  routing  protocol  for  sensor  networks,  where  the  sensors  maintain 
a  spanning  tree  rooted  at  the  base  station.  In  this  program,  whenever  the  parent  of  a  sensor  fails, 
it  chooses  one  of  its  active  neighbors  for  which  the  link  quality  is  greater  than  a  certain  threshold, 
as  its  parent.  Towards  this  end,  the  sensor  has  to  compute  the  link  quality  of  each  of  its  neighbors. 
Specifying  this  action  in  guarded  commands  is  difficult.  Moreover,  nesC/TinyOS  components  may 
exist  that  provide  the  desired  functionality. 

To  simplify  the  design  of  sensor  network  protocols,  ProSe  allows  component  invocations  in  guarded 
commands.  In  the  design  of  routing  protocol,  in  order  to  find  a  neighbor  that  has  a  better  link 
quality,  the  designer  can  invoke  the  component  LinkEstimator  to  compute  the  quality  estimate 
of  a  given  link.  Thus,  parent  update  action  in  the  routing  protocol  can  be  specified  in  guarded 
commands  as  follows: 

1  //  current  parent  (p.j)  has  failed  and  j-k  link  quality  is  greater  than  the  threshold 

2  (up. (p.j)  ==  FALSE)  &&  (up.k  ==  TRUE)  &&  (LinkEstimator .getQuality(k)  >  LINK_THRESHOLD) 

3  ->  p.j  =  k;  currentParentLinkQuality . j  =  LinkEstimator .getQuality(k) ; 

In  the  above  action,  the  getQuality(k)  method  of  LinkEstimator  component  returns  the  quality  of 
the  link  j  —  k.  This  component  may  need  certain  variables  to  compute  the  quality  estimate.  For 
example,  it  may  need  counters  that  maintain  the  number  of  messages  successfully  transmitted  over 
each  link.  The  action  by  which  the  counters  are  updated  would  be  specified  in  guarded  commands. 
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The  variables  used  in  the  guarded  commands  program  and  the  copies  of  the  public  variables  of  the 
neighbors  (maintained  in  Neighbor  State)  are  made  available  to  the  invoked  component. 

The  designer  has  to  implement  LinkEstimator  in  nesC/TinyOS  platform.  This  component,  however, 
uses  only  local  data  (i.e.,  it  uses  NeighborState).  ProSe  generates  the  code  for  NeighborState 
component.  And,  it  wires  the  component  implemented  by  the  designer  with  the  generated  code. 

Output  nesC/TinyOS  code.  In  the  generated  nesC/TinyOS  program,  the  actions  of  the 
input  program  are  executed  whenever  a  timer  fires.  Once  the  sensor  executes  each  action  for  which 
the  corresponding  guard  is  enabled,  it  marshals  all  the  public  variables  as  a  message  wacMsg  and 
schedules  it  for  transmission  (broadcast).  Depending  on  the  transformation  algorithm  and  the 
MAC  layer  selected  by  the  user,  it  configures  when  the  timer  fires  and  how  wacMsg  is  transmitted. 
For  example,  in  case  of  a  TDMA  based  transformation  [16],  ProSe  configures  the  timer  to  fire  in 
every  TDMA  slots  assigned  to  the  sensor.  And,  it  uses  the  TDMA  service  (e.g.,  [16,21,22])  to 
broadcast  the  message.  In  case  of  a  CSMA  based  transformation  [17],  ProSe  configures  the  timer 
to  fire  in  a  random  interval  whenever  it  receives  a  message  containing  values  of  public  variables  at 
the  sender.  And,  it  uses  a  CSMA  service  (e.g.,  [23])  to  broadcast  wacMsg. 

Similarly,  ProSe  generates  code  for  NeighborState  component  that  maintains  the  state  information 
of  the  neighbors  whenever  it  receives  an  update  message  from  one  of  its  neighbors.  Finally,  ProSe 
also  generates  code  to  (1)  initialize  all  the  program  variables,  (2)  configure  network  services  (e.g., 
TDMA,  CSMA),  and  (3)  configure  and  start  middleware  services  (e.g.,  Timer). 

3  Case  Study:  Prototyping  pCover  with  ProSe 

In  this  section,  we  present  a  case  study  on  prototyping  power  management  protocols  with  ProSe. 
We  model  pCover  [13],  a  simple  power  management  protocol  that  provides  partial  (but  high)  sensor 
coverage  of  the  target  field.  Specifically,  pCover  maintains  a  certain  degree  of  coverage  through 
sleep-awake  scheduling  of  sensors.  By  trading  little  sensor  coverage  of  the  field,  in  [13],  the  authors 
show  (using  C+- 1-  discrete  event  simulator)  that  pCover  substantially  improves  the  network  lifetime. 

First,  in  Section  3.1,  we  discuss  the  pCover  program  (written  in  shared-memory  model).  Then, 
in  Section  3.2,  we  show  how  we  synthesize  the  corresponding  nesC/TinyOS  binary  with  ProSe. 
Finally,  in  Section  3.3,  we  evaluate  the  performance  of  the  generated  code. 

3.1  pCover:  Overview 

The  pCover  program  written  in  shared-memory  model  is  shown  in  Figure  1.  The  basic  idea  of 
pCover  is  that  a  sensor  should  turn  itself  off  if  and  only  if  its  local  coverage  is  higher  than  a  certain 
threshold,  called  OnThreshold.  Local  coverage  of  a  sensor  is  the  percentage  of  the  sensor’s  sensing 
area  that  is  covered  by  other  awake  sensors. 

Description  of  the  program.  In  this  program,  each  sensor  is  in  one  of  4  states:  probe,  awake, 
readyoff,  and  sleep.  Each  sensor  j  maintains  one  public  variable  st.j  that  identifies  the  state  of  the 
sensor.  In  addition,  j  maintains  a  copy  of  the  public  variables  of  its  neighbors  (in  NeighborState). 
We  discuss  the  actions  of  the  pCover  program  shown  in  Figure  1  in  detail,  next. 

Probe  state.  A  sensor  in  probe  state  probes  the  environment,  determines  whether  it  should  stay 
awake  or  go  to  sleep.  After  a  timeout  Y,  the  sensor  computes  its  local  coverage.  Note  that  the 
designer  has  to  provide  the  LocalCoverage  component  that  returns  the  local  coverage  of  a  sensor. 
This  component  acts  only  on  the  state  information  of  the  neighbors  maintained  at  the  sensor.  The 
sensor  starts  working  if  its  local  coverage  is  lower  than  the  OnThreshold.  Otherwise,  the  sensor 
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1 

program  pCover 

2 

sensor  j 

3 

const  int  X,  Y,  Z,  S,  W,  OnThreshold,  OffThreshold; 

4 

var 

5 

public  int  st .  j  ; 

6 

private  int  timer.j; 

7 

component  LocalCoverage ; 

8 

begin 

9 

(st.j  ==  SLEEP)  &&  (timer.j  >=  X) 

10 

->  st.j  =  PROBE;  timer.j  =  0; 

11 

1  (st.j  ==  PROBE)  &&  (timer.j  >=  Y)  &&  (LocalCoverage . compute ()  > 

OnThreshold) 

12 

->  st.j  =  SLEEP;  timer.j  =  0; 

13 

1  (st.j  ==  PROBE)  &&  (timer.j  >=  Y)  &&  (LocalCoverage . compute ()  <= 

OnThreshold) 

14 

->  st.j  =  AWAKE;  timer.j  =  Random(0,  S) ; 

15 

1  (st.j  ==  AWAKE)  &&  (timer.j  >=  Z) 

16 

->  st.j  =  READYOFF;  timer.j  =  0; 

17 

1  (st.j  ==  READYOFF)  &&  (timer.j  >=  W) 

18 

->  st.j  =  AWAKE;  timer.j  =  Random(0,  S) ; 

19 

1  (st.j  ==  READYOFF)  &&  (LocalCoverage . compute ()  >  OffThreshold) 

20 

->  st.j  =  SLEEP;  timer.j  =  0; 

21 

1  ((st.j  ==  SLEEP)  &&  (timer.j  <=  X))  I  I 

22 

((st.j  ==  PROBE)  &&  (timer.j  <=  Y))  I  I 

23 

((st.j  ==  AWAKE)  &&  (timer.j  <=  Z))  I  I 

24 

((st.j  ==  READYOFF)  &&  (timer.j  <=  W) ) 

25 

->  timer.j  =  timer.j  +  1; 

26 

end 

Figure  1:  pCover  program  in  ProSe 

switches  to  sleep  state.  The  timeout  Y  is  used  to  ensure  that  when  the  sensor  decides  whether  it 
should  stay  awake  or  go  to  sleep,  it  has  the  fresh  state  information  of  its  neighbors. 

Awake  state.  A  sensor  in  awake  state  actively  monitors  the  area  within  its  sensing  range.  It 
remains  active  until  the  timer  reaches  the  timeout  value  Z .  Since  we  do  not  want  all  awake  sensors 
to  timeout  at  the  same  time,  the  timer  is  initialized  to  a  random  value.  Once  the  awake  timer 
expires,  the  sensor  changes  its  state  to  readyoff. 

Ready  off  state.  In  readyoff  state,  the  sensor  still  provides  sensing  coverage.  However,  the  neighbors 
of  a  readyoff  sensor  (say  j )  consider  j  as  a  sleeping  sensor.  In  other  words,  the  neighbors  of  j  do 
not  count  it  when  they  compute  local  coverage.  If  a  readyoff  sensor  finds  that  its  local  coverage  is 
greater  than  OffThreshold ,  it  will  change  its  state  to  sleep.  Also,  if  a  sensor  is  in  readyoff  state  for  a 
long  duration,  it  can  switch  to  awake  state.  This  action  allows  one  to  deal  with  the  case  where  a  lot 
of  sensors  are  in  readyoff  state  although  none  of  them  can  go  to  sleep  state  (due  to  local  coverage 
being  less  than  OffThreshold). 

Sleep  state.  A  sensor  in  sleep  state  wakes  up  every  X  minutes.  When  it  wakes  up,  it  changes  its 
state  to  probe  and  proceeds  to  execute  actions  in  that  state. 

3.2  Transformation  and  Code  Generation 

We  use  ProSe  to  generate  the  nesC/TinyOS  implementation  of  the  pCover  program  and  sub¬ 
sequently  build  the  binary  image.  Towards  this  end,  we  use  the  TDMA  based  transformation 
from  [16]  to  transform  the  program  into  WAC  model  and  generate  the  nesC/TinyOS  code.  We 
integrate  SS-TDMA  [21]  with  the  generated  program  to  implement  the  write-all  action.  As  men¬ 
tioned  in  Section  2,  since  the  pCover  program  includes  component  invocation  (LocalCoverage)  in 
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the  actions,  we  require  the  designer  of  the  protocol  to  implement  this  component  in  nesC/TinyOS. 
We  discuss  how  the  designer  implements  this  component  and  how  ProSe  integrates  it  with  the 
generated  code,  next. 

LocalCoverage  component.  Based  on  the  state  information  of  the  neighbors  of  a  sensor  (say, 
j),  LocalCoverage  component  computes  the  percentage  of  j's  sensing  area  that  is  covered  by  its 
awake  neighbors.  This  component  provides  a  method  ( compute ( ))  that  could  be  invoked  in  the 
guarded  commands  program.  This  method  returns  the  local  coverage  of  the  sensor. 

In  order  to  compute  the  local  coverage  of  the  sensor,  LocalCoverage  requires  the  state  information 
of  the  neighbors  of  the  sensor.  This  information  is  maintained  by  NeighborState  component  (as 
mentioned  in  Section  2).  Since,  ProSe  wires  NeighborState  with  LocalCoverage  when  generating 
the  nesC/TinyOS  code  for  pCover,  LocalCoverage  component  can  obtain  the  state  information  of 
the  neighbors  of  the  sensor  by  invoking  NeighborState.  Note  that  all  accesses  to  NeighborState  are 
local  and  ProSe  is  responsible  for  updating  NeighborState  with  fresh  values.  Thus,  the  designer 
does  not  have  to  deal  with  programming  level  challenges  of  nesC/TinyOS  platform  and  low-level 
challenges  of  sensor  networks  (e.g.,  communication,  collisions,  corruption,  etc). 

3.3  Evaluation  of  the  Synthesized  Program 

We  evaluate  the  performance  of  the  generated  nesC/TinyOS  code  for  pCover  with  TOSSIM  [24],  a 
discrete  event  simulator  for  Tiny  OS  sensor  networks. 

Simulation  settings.  We  use  the  simulation  setting  similar  to  [13].  We  deploy  the  sensors 
in  a  grid  topology  over  a  100m  X  100m  area.  We  set  the  sensing  range  r  of  the  sensors  to  10m 
and  the  radio  interference  range  to  50m.  We  vary  the  density  of  the  sensors  from  1  node/r2  to 
4  nodes/r2.  Inter-sensor  separation  and  the  number  of  sensors  deployed  varies  depending  on  the 
density.  With  1  node/r2  (respectively,  2  nodes/r2  and  4  nodes/r2),  the  inter-sensor  separation  is 
10m  (respectively,  7m  and  5m)  and  the  network  size  is  10x10  (respectively,  14x14  and  20x20).  SS- 
TDMA  [21]  sets  the  TDMA  period  depending  on  the  number  of  sensors  falling  in  the  interference 
range  of  a  sensor.  With  1  node/r2  (respectively,  2  nodes/r2  and  4  nodes/r2),  SS-TDMA  sets  the 
period  to  50  (respectively,  100  and  200)  slots,  where  one  time  slot  =  30ms. 

We  assume  that  the  lifetime  of  a  sensor  is  20  minutes.  We  choose  this  value  in  order  to  ensure 
that  the  simulation  completes  within  a  reasonable  time.  (With  density  of  4  nodes/r2,  the  sim¬ 
ulation  takes  4  days  to  complete.  Typically,  sensors  are  expected  to  work  continuously  for  1000 
minutes.  Simulating  a  sensor  lifetime  of  1000  minutes  in  TOSSIM,  however,  would  approximately 
take  200  days  to  complete.)  We  simulate  the  lifetime  of  each  sensor  by  maintaining  a  variable  and 
decrementing  it  appropriately  in  each  time  slot. 

In  all  our  simulations,  we  set  the  timeout  values  for  pCover  as  follows:  X  =  1  minute,  Y  =  2  TDMA 
slots,  Z  =  3  minutes,  and  S  =  W  =  2  minutes.  We  randomly  initialize  the  state  of  each  sensor. 
We  set  OnThreshold  and  OffThreshold  to  0.7  and  0.6.  We  consider  that  a  network  is  “dead”  when 
the  global  coverage  of  the  network  is  less  than  a  certain  threshold  even  if  all  the  alive  nodes  are 
working.  Global  coverage  (or  degree  of  coverage)  is  the  percentage  of  the  field  that  is  covered  by 
the  working  nodes.  We  define  network  lifetime  as  the  duration  from  the  beginning  of  deployment 
until  the  network  is  dead.  We  use  50%  as  the  threshold  in  our  simulations. 

In  our  simulations,  each  link  in  the  network  has  a  bit  error  probability,  representing  the  probability 
that  a  bit  can  be  corrupted  if  it  is  sent  along  the  link.  Bit  errors  for  each  link  is  decided  inde¬ 
pendently  (using  LossyBuilder,  a  Java  program  in  TinyOS  release)  based  on  empirical  loss  data 
gathered  from  real  world  [25].  Next,  we  discuss  our  simulation  results. 
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3.3.1  Coverage  and  Network  Lifetime 


In  Figure  2,  we  show  the  degree  of  coverage  and  number  of  active  sensors  over  time  for  different 
network  densities.  In  our  simulations,  we  compute  the  global  coverage  for  the  entire  100m  X 
100m  field  and  for  the  inner  80m  X  80m  field.  The  border  sensors  contribute  only  a  part  of  their 
sensing  range  in  the  held  and,  hence,  we  consider  the  inner  80m  X  80m  held,  where  there  is  no 
such  edge  effect.  As  we  can  see  from  Figures  2(a)  and  2(b),  the  sensors  maintain  the  coverage  at 
approximately  the  same  level.  With  density  =  4  nodes/?’2,  initially  (i.e.,  around  3  minutes),  we 
observe  a  drop  in  the  coverage.  This  is  due  to  the  fact  that  large  number  of  sensors  are  initially 
set  to  active  state  (as  a  result  of  random  initialization)  and  the  number  of  active  sensors  fluctuate 
before  converging  to  an  appropriate  number  that  maintains  the  coverage  at  a  certain  level  (around 
94%).  Figure  2(c)  shows  the  number  of  active  sensors  over  time.  As  we  can  observe  from  the  hgure, 
this  number  remains  at  the  same  level  until  the  point  where  the  coverage  starts  dropping. 


Figure  2:  Coverage  and  number  of  active  sensors  over  time;  (a)  coverage  of  entire  100m  X  100m 
area,  (b)  coverage  of  inner  80m  X  80m  area,  and  (c)  number  of  active  sensors. 


From  Figures  2(a)  and  2(b),  we  observe  that  the  coverage  is  well  maintained  until  one  point,  after 
which,  the  coverage  drops  suddenly,  and  the  network  dies  in  a  short  period.  This  shows  that  pCover 
maintains  a  balanced  energy  consumption  as  all  sensors  run  out  of  power  at  around  the  same  time. 
Also,  we  confirm  the  result  in  [13];  by  sacrificing  little  coverage,  the  network  lifetime  is  extended. 
Specifically,  the  lifetime  with  densities  of  2  nodes/r2  (respectively,  4  nodes/?-2)  is  around  56  minutes 
(respectively,  62  minutes). 


3.3.2  Quality  of  Coverage 

As  mentioned  in  [13],  in  partially  covered  sensor  networks,  quality  of  coverage  is  an  important 
metric.  For  example,  in  surveillance  networks,  it  is  measured  in  terms  of  how  fast  the  sensors 
detect  a  target  object.  Since  the  sleep  interval  (i.e.,  X)  is  1  minute,  time  to  detect  stationary 
objects  in  the  sensor  field  is  bounded  by  1  minute.  Additionally,  since  the  sensors  rotate  their  roles 
(working  vs.  sleeping),  the  set  of  active  sensors  changes  continuously.  Hence,  an  undetected  “hole” 
is  likely  to  be  detected  as  the  set  of  active  sensors  changes.  In  Figure  3,  we  show  the  snapshots  of 
the  held  at  different  times. 

From  Figure  3,  we  observe  that  the  location  of  “holes”  change  continuously.  In  surveillance  net¬ 
works,  the  intruder  does  not  know  the  location  of  such  holes.  Hence,  it  is  unlikely  that  the  intruder 
can  choose  to  move  along  the  uncovered  path.  Therefore,  the  time  to  detect  the  intruder  is  small 
on  average. 
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(a)  20  minutes  (b)  30  minutes  (c)  40  minutes  (d)  50  minutes 

(coverage:  94.3%/96.9%)  (coverage:  91.8%/92%)  (coverage:  91.8%/95.9%)  (coverage:  84.7%/88.3%) 


Figure  3:  Snapshot  of  the  field  with  density  =  4  nodes/r2  (dark  regions  are  covered).  Coverage 
data  below  each  subfigure  shows  the  coverage  of  entire  area  and  the  coverage  of  inner  80m  X 
80m  area  respectively  at  that  time. 

4  Discussion  and  Related  Work 

In  this  section,  we  discuss  some  of  the  questions  raised  by  this  work  and  the  related  work  on 
programming  platforms  and  power  management  protocols  for  sensor  networks. 

4.1  Other  Power  Management  Protocols 

It  is  possible  to  prototype  other  power  management  protocols  with  ProSe  as  well.  To  illustrate 
this,  in  this  section,  we  specify  another  power  management  protocol,  namely,  the  differentiated 
surveillance  program  from  [7].  We  discuss  this  program  and  present  the  program  in  guarded 
commands  format  (cf.  Figure  4).  For  reasons  of  space,  in  this  paper,  we  do  not  discuss  performance 
evaluation  of  the  generated  nesC/TinyOS  code  of  this  program. 

Description  of  the  program.  In  this  program,  sensors  operate  in  two  phases:  (i)  initialization 
and  (ii)  sensing.  During  initialization  phase,  the  sensors  compute  the  working  schedule  that  specifies 
when  a  sensor  should  sleep  and  when  it  should  provide  sensing  coverage.  In  the  sensing  phase,  time 
is  divided  into  rounds  with  equal  duration  (T).  The  sensors  execute  depending  on  their  schedule 
in  each  round. 


1  program  Dif f erentiatedSurveillance 

2  sensor  j 

3  const  int  T; 

4  var 

5  public  int  Ref  .  j  ; 

6  private  int  phase. j,  st.j,  Tf.j,  Te.j; 

7  component  CWindow; 

8  begin 

9  (phase. j  ==  INIT)  &&  CWindow. computeCoverageWindow(Ref . j ,  T) 

10  ->  phase. j  =  SENSE;  st.j  =  SLEEP; 

n  Tf . j  =  CWindow. getStartTime O ;  Te.j  =  CWindow. getEndTime O ; 

12  |  (phase. j  ==  SENSE)  &&  (st.j  ==  SLEEP)  && 

13  ( (Ref .  j  -  Tf.j  -  1)  <  (TIME  7,  T))  &&  ((TIME  T)  <=  (Ref.j  -  Tf.j)) 

14  ->  st . j  =  AWAKE; 

15  I  (phase. j  ==  SENSE)  &&  (st.j  ==  AWAKE)  && 

16  ((Ref.j  +  Te.j)  <  (TIME  "/.  T) )  &&  ((TIME  7,  T)  <=  (Ref.j  +  Te.j  +  1)) 

17  ->  st . j  =  SLEEP; 

18  end 

19  init  state  phase,  j  =  INIT;  Ref.j  =  Random(0,  T)  ; 


Figure  4:  Surveillance  program  from  [7]  in  ProSe 


Each  sensor  j  maintains  a  public  variable  Ref.j,  a  random  time  reference  point  chosen  by  j  within 
[0,  T).  The  component  CWindow  computes  the  time  when  j  should  wake  up  (i.e.,  Ref.j  —  Tf.j )  and 
when  it  should  go  to  sleep  (i.e.,  Ref.j+Te.j )  in  each  round.  Specifically,  depending  on  the  i?e/values 
of  the  neighbors  of  j  (maintained  by  NeighborState),  CWindow  computes  Tf.j  and  Te.j  for  each 
point  in  the  sensing  range  of  j  such  that  the  point  is  covered  100%  of  the  time.  Once  it  computes 
the  schedule  for  all  points  in  the  j’s  sensing  range,  it  computes  the  integrated  working  schedule  for 

j- 

The  program  shown  in  Figure  4  invokes  computeCoverageWindowf)  method  of  CWindow  to  de¬ 
termine  whether  the  sensor  can  enter  the  sensing  phase.  This  method  returns  TRUE  only  when 
j  has  received  the  state  information  of  all  its  neighbors.  When  this  method  returns  TRUE ,  the 
sensor  starts  executing  the  sensing  phase  according  to  the  computed  schedule.  The  program  calls 
getStartTimef)  and  getEndTimef)  methods  of  CWindow  to  get  the  working  schedule  of  j.  In  Figure 
4,  the  program  uses  the  keyword  TIME  to  determine  when  the  sensor  should  go  to  sleep  or  stay 
awake.  TIME  represents  the  system  time  and  ProSe  adds  code  to  get  the  system  time  and  keep 
it  synchronized. 

Transformation  and  code  generation.  We  generate  the  nesC/TinyOS  implementation  of 
the  program  shown  in  Figure  4  with  ProSe.  We  use  the  TDMA  based  transformation  from  [16]  to 
transform  this  program  into  WAC  model  and  integrate  SS-TDMA  [21]  with  the  generated  code. 
Again,  in  this  program,  we  require  the  designer  to  implement  CWindow  in  nesC/TinyOS.  ProSe 
integrates  NeighborState  with  CWindow. 

4.2  Lessons  Learned  in  Prototyping  Power  Management  Protocols 

In  this  section,  we  discuss  some  of  the  lessons  learned  in  prototyping  power  management  protocols 
with  ProSe. 

Rapid  prototyping  and  quick  evaluation.  Most  of  the  power  management  protocols  for 
sensor  networks  follow  the  event-driven  model.  For  example,  in  pCover  (cf.  Section  3)  and  differ¬ 
entiated  surveillance  (cf.  Section  4.1),  we  observe  that  a  sensor  switches  to  either  working  mode 
or  sleeping  mode  whenever  an  event  occurs  (such  as  a  timeout).  Since  guarded  commands  format 
is  event-driven  in  nature,  prototyping  power  management  protocols  with  ProSe  is  straightforward. 
Furthermore,  the  time  required  to  prototype  protocols  with  ProSe  is  small.  For  example,  the  time 
required  to  prototype  pCover  with  ProSe  was  in  the  order  of  few  minutes.  Also,  the  time  required 
to  specify  LocalCoverage,  a  component  used  to  compute  the  percentage  of  a  sensor’s  sensing  region 
covered  by  other  active  neighbors,  was  in  the  order  of  couple  of  hours.  As  mentioned  in  Section  3.2, 
this  component  uses  only  local  data  and,  hence,  we  did  not  have  to  worry  about  communication. 
As  a  result,  specifying  this  component  in  nesC/TinyOS  platform  was  quick.  By  contrast,  had  we 
chosen  to  prototype  pCover  directly  in  nesC/TinyOS,  we  would  have  to  deal  with  all  low-level 
challenges  of  sensor  networks  and  progrannning-level  challenges  of  the  platform.  Based  on  our 
experience  in  developing  protocols  with  nesC/TinyOS,  we  expect  this  effort  to  take  considerable 
time  (usually,  few  days  to  couple  of  weeks). 

In  short,  ProSe  provides  a  way  to  rapidly  prototype  power  management  protocols  and  generate  the 
corresponding  nesC/TinyOS  implementation.  Hence,  the  designers  can  quickly  deploy  and  easily 
evaluate  their  protocols. 

Preserving  properties  of  interest.  Since  designers  specify  protocols  in  guarded  commands 
format  (with  ProSe),  they  can  analyze  them  for  properties  such  as  fault-tolerance,  self-stabilization, 
and  reliability.  In  addition,  the  designers  can  automatically  add  new  properties  to  the  guarded 
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commands  program.  For  example,  the  designers  can  use  FTSyn  [26]  to  automatically  add  fault- 
tolerance  properties  to  their  programs.  If  the  transformation  algorithm  used  to  transform  the 
input  program  (in  shared-memory  model  or  read/write  model)  into  a  model  consistent  with  sensor 
networks  (i.e.,  write  all  with  collision  model  [16,  17])  preserves  properties  of  interest  then  ProSe 
also  preserves  such  properties.  Thus,  ProSe  simplifies  the  design  of  power  management  protocols 
while  ensuring  that  the  properties  of  interest  are  preserved  in  the  transformed  programs. 

4.3  Related  Work 

Work  related  to  rapid  prototyping  of  power  management  protocols  can  be  categorized  as:  (i) 
programming  platforms  and  (ii)  power  management  protocols. 

Programming  platforms.  Related  work  that  deals  with  programming  abstractions  include 
[27-30]  and  tools  for  programming  sensor  networks  include  [20,31-36]. 

Programming  abstractions.  In  [27],  a  state  centric  approach  is  proposed  that  captures  algorithms 
such  as  sensor  fusion,  signal  processing  and  control.  In  this  model,  the  abstraction  of  collaboration 
groups  hides  the  designer  from  issues  such  as  communication  protocols,  event  handling,  etc.  In 
[28,29],  macroprogramming  primitives  that  abstract  communication,  data  sharing  and  gathering 
operations  are  proposed.  However,  these  primitives  are  application-specific  (e.g.,  abstract  regions 
for  tracking  and  gathering  [28]  and  region  streams  for  aggregation  [29]).  And,  in  [30],  semantic 
services  programming  model  is  proposed  where  users  only  specify  the  end  goal  on  what  semantic 
data  to  collect.  Unlike  [27-30],  ProSe  allows  the  designer  to  evaluate  existing  algorithms  in  the 
context  of  sensor  networks.  Moreover,  since  the  programs  are  written  in  abstract  models  considered 
in  distributed  systems,  ProSe  permits  the  designer  to  verify  the  correctness  of  the  programs  as  well 
as  to  manipulate  the  programs  to  meet  new  properties. 

Programming  tools.  Techniques  like  virtual  machine  (e.g.,  Mate  [31]),  middleware  (e.g.,  Enviro- 
Track  [32]),  library  (e.g.,  SNACK  [33]),  and  database  (e.g.,  TinyDB  [34])  are  proposed  for  simplify¬ 
ing  programming  sensor  network  applications.  However,  these  solutions  are  (i)  application-specific, 
and/or  (ii)  restrict  the  designer  to  what  is  available  in  the  virtual  machine,  middleware,  library,  or 
network.  In  [36],  macroprogramming  model,  called  Kairos,  that  hides  the  details  of  code-generation 
and  instantiation,  data  management,  and  control  is  proposed.  However,  unlike  [20,31-36],  ProSe 
hides  low-level  details  such  as  message  collisions,  corruption,  sensor  failures,  etc.  Moreover,  ProSe 
does  not  require  any  runtime  support. 

Power  management  protocols.  Related  work  on  power  management  protocols  for  sensor 
networks  include  [7-13].  In  [9],  a  sensor  is  allowed  to  go  to  sleep  if  and  only  if  one  of  its  neighbors 
can  completely  cover  its  sensing  area.  As  identified  by  [7] ,  this  approach  underestimates  the  coverage 
provided  by  neighboring  sensors  and,  hence,  it  leads  to  energy  waste.  Additionally,  both  [7]  and  [9] 
require  a  global  synchronization  service.  In  [10],  a  coverage  configuration  protocol  is  proposed 
where  a  sensor  can  switch  to  sleep  state  if  all  intersection  points  inside  its  sensing  range  are  at 
least  k-covered  (i.e.,  a  point  is  covered  by  at  least  k  sensors).  However,  unlike  [13],  this  approach 
requires  more  number  of  active  sensors. 

Power  management  protocols  proposed  in  [8,  11,  13]  follow  similar  design  principles.  However, 
unlike  [11, 13],  in  [8],  a  working  sensor  is  awake  continuously  until  its  failure  or  depletion  of  power. 
In  [8,  11],  by  controlling  the  range  of  messages  transmitted,  the  density  of  working  sensors  is 
controlled.  However,  online  estimation  of  transmission  ranges  and  the  number  of  working  sensors 
are  often  difficult  and  inaccurate. 
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5  Conclusion 


In  this  paper,  we  considered  the  problem  of  rapid  prototyping  of  power  management  protocols  for 
sensor  networks.  Since  existing  programming  platforms  (e.g.,  nesC/TinyOS)  require  the  designers 
to  be  responsible  for  stack  management,  buffer  management,  and  flow  control,  the  designers  of  power 
management  protocols  prototype  the  protocols  either  by  implementing  a  discrete  event  simulator 
or  by  modeling  in  a  specialized  simulator  such  as  GloMoSim  [14].  To  enable  rapid  prototyping 
and  quick  evaluation  of  power  management  protocols  in  the  target  platform  (e.g.,  nesC/TinyOS  for 
Mica,  XSM,  or  Telos  based  sensor  networks),  in  this  paper,  we  demonstrated  how  the  designers  can 
prototype  their  protocols  with  ProSe.  ProSe  is  programming  tool  for  sensor  networks  that  enables 
the  designers  to  (i)  specify  programs  in  simple  abstract  models,  (ii)  transform  them  into  a  model 
consistent  with  sensor  networks,  (iii)  preserve  properties  of  interest  in  the  transformed  programs, 
and  (iv)  automatically  generate  and  deploy  nesC/TinyOS  code. 

As  a  case  study,  we  specified  the  power  management  program  from  [13]  with  ProSe,  generated  the 
corresponding  nesC/TinyOS  code,  and  evaluated  its  performance  on  TOSSIM  [24],  We  showed  that 
the  synthesized  program  provides  partial  (but  high)  coverage  of  the  sensor  field.  We  also  specified 
other  power  management  protocols  with  ProSe  and  showed  that  the  time  required  to  prototype 
such  protocols  is  small. 

Since  ProSe  hides  low-level  challenges  of  sensor  networks  (e.g.,  message  collision,  corruption,  syn¬ 
chronization,  etc)  and  programming  level  challenges  (e.g.,  buffer  management,  stack  management, 
etc),  the  designers  can  rapidly  prototype  their  protocols  and  generate  code  in  the  target  platform. 
As  a  result,  the  development  time  and  deployment  time  are  small.  In  this  paper,  we  illustrated 
this  by  prototyping  pCover  [13]  and  differentiated  surveillance  [7]  programs  with  ProSe.  Thus, 
with  ProSe,  we  expect  that  the  designers  can  rapidly  prototype,  quickly  deploy  and  easily  evaluate 
power  management  protocols  in  the  target  platform. 
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